The word “bloat” is sometimes used to describe software X which is slower, bigger, more complicated to use, or more demanding of resources than some other software Y. Software Y could be a previous version of X, or a competing product, or a hypothetical product, for example. Responses to perceived software bloat, and proactive efforts to reduce or prevent bloat, take a wide range of forms, many of which complement one another.
For example, architects of some systems divide system functionality into a core operating system and a number of discrete related utility programs. The functionality of each individual utility is (at least in theory) narrowly constrained, e.g., performing file compression/decompression in a specified file format, searching for a specified string, listing the filenames in a specified directory, copying a specified file, and so on. Pipes, scripts, and/or other connective mechanisms are provided through a command interpreter to permit customized combinations of the utility programs which focus (at least initially) on a particular well-defined problem or purpose.
As another example, in some programming environments compiler preprocessor directives can be used by a developer to either include or exclude delimited portions of source code in a compilation. Thus, code that contains print statements to aid debugging may be included in development binary versions of a program but excluded from a publicly released production binary.
As a further example, some web browsers support add-on or plug-in functionality. The add-ons may be downloaded as separate items, are often not installed at the same time as the browser's core component(s), are not required for basic browser functionality such as viewing web pages, and are often created by vendors other than the browser vendor.